1 MySQL日志

1.1 錯誤日志

文件名：可用–log-error[=file_name]指定，否則默認使用hostname.err

內容：記錄mysqld啟動和停止時，以及服務器發生任何嚴重錯誤時記錄相關信息

1.2 二進制日志

文件名：也是binlog(邏輯日志)，可用–log-bin[=file_name] 指定，默認為主機名

內容：包含了所有更新了或者潛在更新了數據的所有語句，語句以“事件”的形式保存，描述數據更改文件位置和格式

查看日志：

mysqlbinlog log-file

刪除日志：

#刪除所有的binlog日志，新日志從頭開始編號
RESET MASTER
#刪除mysql-bin.010之前的所有日志
PURGE MASTER LOGS TO 'mysql-bin.010'
#刪除2022.5.1之前的binlog日志
purge master logs before '2022-05-01 08:00:00';

1.3 查詢日志

文件名：使用–log指定，默認hostname.log

內容：記錄客戶端所有查詢語句記錄，在二進制日志不存在查詢語句記錄

1.4 慢查詢日志

文件名：使用–log-slow-querie指定，默認*-slow.log，寫入data目錄

內容：記錄執行時間超過long_query_time秒的SQL查詢日志文件

其它選項：–log_slow_admin_statements：表示將慢管理語句，如OPTIMIZE TABLE、ANALYZE TABLE和ALTER TABLE寫入慢查詢語句

1.5 通用查詢日志

查看：show variables like '%general_log%';

執行SQL命令 set global general_log=on; 開啟

文件：默認存放在data目錄下hostname.log文件

內容：記錄客戶端的所有查詢行為

1.6 中繼日志

文件：默認文件名hostnamet-relay-bin，存放在data目錄下

功能：從服務器I/O線程將主服務器的二進制日志讀取過來記錄到從服務器本地文件，然后從服務器SQL線程會讀取relay-log日志的內容并應用到從服務器，從而使從服務器和主服務器的數據保持一致

參數：show variables like '%relay%';

• max_relay_log_size
  • relay log 允許的最大值，如果該值為0，則默認值為 max_binlog_size (1G)
  • 如果不為0，則 max_relay_log_size 則為最大的relay_log文件大小
• relay_log
  • 定義 relay_log 的位置和名稱，如果值為空，則默認位置在數據文件的目錄
• relay_log_index
  • 定義 relay_log 索引的位置和名稱，記錄有幾個 relay_log 文件，默認為2個
• relay_log_info_file
  • 定義 relay-log.info 的位置和名稱，relay-log.info 記錄 master 主庫的 binary_log 的恢復位置和 從庫 relay_log 的位置
• relay_log_purge
  • 是否自動清空中繼日志，默認值為1(啟用)
• relay_log_recovery
  • 當slave從庫宕機后，假如relay-log損壞了，導致一部分中繼日志沒有處理，則自動放棄所有未執行的relay-log，并且重新從master上獲取日志，這樣就保證了relay-log的完整性。默認情況下該功能是關閉的，將relay_log_recovery的值設置為 1時，可在slave從庫上開啟該功能，建議開啟
• sync_relay_log
  • 當設置為1時，slave的I/O線程每次接收到master發送過來的binlog日志都要寫入系統緩沖區，然后刷入relay log中繼日志里，這樣是最安全的，因為在崩潰的時候，你最多會丟失一個事務，但會造成磁盤的大量I/O
  • 當設置為0時，并不是馬上就刷入中繼日志里，而是由操作系統決定何時來寫入，雖然安全性降低了，但減少了大量的磁盤I/O操作。這個值默認是0，可動態修改
• sync_relay_log_info
  • 這個參數和 sync_relay_log 參數一樣

1.7 審計日志

內容：企業版自帶功能，社區版需使用audit審計插件完成數據庫審計工作

開啟步驟：

• 下載插件：https://github.com/mcafee/mysql-audit

• 查看插件功能是否開啟： show variables like "%audit%";

• 開啟插件功能：set global audit_json_file=1;

  注意，使用此方法開啟對global全局變量的設置僅對于新開啟的會話才是有效的，對已經開啟的會話不生效，參數最終需持久化到my.cnf配置文件中

• 開啟后，在MySQL數據目錄下會多出一個mysql-audit.json審計日志

2 InnoDB日志

2.1 重做日志 (Redo Log)

文件：默認情況下，對應的物理文件位于數據庫的data目錄下的ib_logfile1&ib_logfile2

內容：物理日志，記錄物理數據頁面的修改信息，redo log順序寫入redo log file物理文件中

重做日志有一個緩沖區Innodb_log_buffer，InnoDB優先將重做日志寫入緩沖區，日志寫盤通常有三種方式：

• Master Thread 每秒一次執行刷新Innodb_log_buffer到重做日志文件

• 每個事務提交時會將重做日志刷新到重做日志文件。

• 當重做日志緩存可用空間 少于一半時，重做日志緩存被刷新到重做日志文件

因此，重做日志的寫盤，并不一定是隨著事務的提交才寫入重做日志文件的，而是隨著事務的開始逐步開始的，這可以很好地解釋再大的事務的提交（commit）的時間也是很短暫的

事務產生的重做日志，通過innodb_flush_log_at_trx_commit參數控制：

• 設置為 0 的時候，表示不寫入buffer，直接每秒寫入到redo file中，但mysql 崩潰會丟失1s數據
• 設置為 1 的時候，表示每次事務提交時都將 redo log 直接持久化到磁盤
• 設置為 2 的時候，表示每次事務提交時都只是把 redo log 寫到 page cache，由OS處理回寫磁盤操作，OS宕機會丟失數據

2.2 回滾日志(Undo Log)

文件：邏輯日志，記錄在表空間中

• MySQL5.6之前，undo表空間位于共享表空間的回滾段中，共享表空間的默認的名稱是ibdata，位于數據文件目錄中

• MySQL5.6之后，undo表空間可以配置成獨立的文件，但是提前需要在配置文件中配置，完成數據庫初始化后生效且不可改變undo log文件的個數

內容：記錄數據的邏輯變化，一條INSERT會對應一條DELETE的undo log，發生錯誤時能夠恢復到事務之前的數據狀態

undo log是MVCC(多版本并發控制)實現的關鍵